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ABSTRACT 


This  Report  gives  a  brief  background  summary  of  the  PLANS 
development  program,  and  provides  a  general  description  of  the 
DREO  Experimental  Development  Model  ( XDM )  of  a  Primary  Land 
Arctic  Navigation  System  (PLANS).  This  includes  a  generic 
description  of  the  essential  PLANS  hardware  requirements 
(processors,  memory,  interfaces,  displays,  sensors  etc.)  as  well 
as  the  specific  hardware  used  in  the  XDM.  A  high  level 
description  of  the  software  structure  and  data  flow  is  given.  A 
brief  general  description  of  the  salient  functional 
characteristics  of  PLANS  is  presented,  including  the  accuracy 
performance.  Also  provided  is  an  extensive  list  of  references  for 
further  detailed  information  on  the  various  components  of  the 
PLANS  XDM. 


RESUME 


Ce  rapport  donne  une  breve  description  du  programme  de 
developpement  de  PLANS  ainsi  qu'une  description  generale  du 
modele  de  developpement  experimental  d'un  systeme  de  navigation 
terrestre  pour  l'artique  (PLANS)  developpe  au  CRDO.  Les 
exigences  minimales  pour  les  composantes  de  PLANS  (processeur, 
memoire,  interfaces,  affichages,  senseurs,  etc.)  sont  discutees, 
ainsi  que  les  composantes  specifiques  utilisees  pour  le  modele  de 
developpement.  Une  description  generale  du  logiciel  est  donnee. 
Un  resume  des  principales  caracteristiques  fonctionnelles  de 
PLANS  sont  presentees,  incluant  la  precision  du  systeme.  Une 
liste  de  references  est  incluse,  fournissant  plus  d' information 
sur  les  diverses  composantes  du  systeme. 
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EXECUTIVE  SUMMARY 


The  Canadian  Forces  Mobile  Command  has  had  a  longstanding 
requirement  for  an  Arctic  navigation  system.  In  December  1982 
DLAEEM  3-2  tasked  DREO  with  the  development  of  a  Primary  Land 
Arctic  Navigation  System  (PLANS)  to  meet  this  requirement.  DREO 
has  therefore  designed  and  prototyped  a  PLANS,  based  on  the 
optimal  (Kalman  filter  based)  integration  of  a  carefully  chosen 
set  of  sensors.  This  design,  in  the  form  of  an  experimental 
development  model  ( XDM )  has  been  shown  through  field  trials  at 
DREO,  Petawawa  and  Iqaluit  (Frobisher  Bay)  to  meet  the  basic 
functional  and  accuracy  requirements,  but  has  not  been  evaluated 
against  the  environmental  requirements. 


The  sensors  chosen  for  PLANS  are  all  commercially 
available,  and  they  fall  into  two  categories:  the  self  contained 
dead  reckoning  (DR)  sensors  and  the  external  aiding  sensors.  The 
primary  self  contained  sensors  are  the  vehicle  odometer  and  a 
gyro  unit.  These  measure  the  vehicle  velocity,  from  which  the 
position  can  be  determined  from  a  known  starting  point.  This  DR 
solution  is  aided  by  another  self  contained  sensor:  a  magnetic 
heading  sensor,  which  can  be  used  to  initialize  the  gyro  heading 
at  extreme  latitudes  (where  the  gyro  unit  may  be  unable  to 
adequately  perform  the  necessary  gyrocompassing  to  find  the 
initial  heading ) . 


The  external  aiding  sensors  are  satellite  positioning 
systems,  which  rely  on  radio  transmissions  from  the  Transit  or 
GPS  satellites.  The  initial  PLANS  design  relied  on  Transit,  which 
produces  a  position  fix  roughly  once  every  hour.  The  GPS  receiver 
produces  more  accurate  position  fixes,  and  they  are  essentially 
continuous  when  a  sufficient  number  of  GPS  satellites  are 
visible.  As  more  GPS  satellites  are  launched,  the  gaps  in 
visibility  will  decrease  and  disappear,  at  which  point  the 
Transit  receiver  will  no  longer  be  required. 

An  essential  feature  of  the  DREO-developed  PLANS  is  the 
multisensor  integration  Kalman  filter  and  prefilter  software, 
with  its  error  detection,  error  correction,  dynamic  calibration 
and  sensor  blending.  This  PLANS  filter  and  prefilter  are  based  on 
detailed  stochastic  error  models  developed  at  DREO,  as  described 
in  the  DREO  report  of  reference  2.1.2.  Therefore  the  particular 
choice  of  sensors  (ie.  the  brands  and  models)  is  not  critical  to 
the  PLANS  design.  However  certain  fundamental  characteristics  are 
required  of  each  sensor  type,  as  described  in  this  report. 

For  test  and  evaluation  purposes  DREO  built  an 
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exploratory  development  model  ( XDM )  PLANS,  using  a  particular  set 
of  appropriate  sensors.  These  consist  of  a  Lear  Siegler  gyro  unit 
(from  the  Lear  Siegler  VNAS ) ,  a  Magnavox  MX1107  dual  channel 
Transit  receiver,  upgraded  to  include  a  single  channel  C/A  code 
GPS  card,  a  Marinex  two  axis  gymballed  magnetic  fluxgate  sensor 
(magnetic  compass  900111),  a  Setra  high  output  pressure 
transducer  model  205-2  (as  a  baroaltimeter  to  provide  height)  and 
the  vehicle  odometer  pickoff  from  the  Lear  Siegler  VNAS.  The 
interfacing  and  data  flow  from  these  sensors  is  described  in  this 
report.  Although  these  units  have  been  shown  to  be  capable  of 
meeting  the  system  functional  requirements,  for  the  advanced 
development  model  (ADM),  which  should  be  built  by  early  1990, 
equivalent  or  better  sensors  may  be  substituted.  This  could  of 
course  require  a  corresponding  interface  change,  and  possibly 
some  minor  integration  software  changes.  In  the  case  of  the 
keypad  and  displays,  the  XDM  hardware  is  definitely  not  capable 
of  meeting  the  ADM  requirement,  so  this  at  least  must  be 
replaced . 

The  PLANS  XDM  processor  is  based  on  the  Motorola  68000 
microprocessor.  It  is  equipped  with  over  600K  of  memory  and 
various  interface  modules,  as  described  more  fully  in  this 
report . 

The  PLANS  software  is  written  in  the  high  level  "C" 
language.  This  software  is  modular  and  hierarchical,  with  seven 
major  tasks.  These  are  the  navigation  task,  the  Kalman  filter 
task,  the  control/display  unit  task,  the  keypad  unit  task,  the 
data  collection  task,  the  serial  port  listener  task,  and  the  data 
logger  task. 

This  report  provides  an  overview  of  the  PLANS  software 
structure  with  an  overall  dataflow  diagram  showing  how  the  seven 
major  tasks  are  interrelated.  More  detailed  flow  diagrams  are 
also  given  showing  the  general  work  cycle  of  each  of  these  tasks. 
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BACKGROUND 


The  Canadian  Forces  Mobile  Command  has  had  a  longstanding 
requirement  for  an  Arctic  navigation  system.  Various  factors 
combine  to  make  Arctic  navigation  very  difficult,  such  as  the 
lack  of  recognizable  land  features,  frequent  poor  visibility,  a 
weak  and  fluctuating  horizontal  magnetic  field  component 
(effecting  magnetic  compasses),  an  absence  of  radio  navigation 
aid  signals,  and  a  low  horizontal  earth  rate  (effecting  the 
accuracy  of  gyrocompasses  at  high  latitudes).  These  difficulties, 
together  with  the  grave  danger  associated  with  being  lost  in  such 
a  hostile  environment,  lead  to  a  requirement  for  an  automatic, 
all-weather  Arctic  navigation  system.  In  December  1982  DLAEEM  3-2 
therefore  tasked  DREO  with  the  development  of  a  Primary  Land 
Arctic  Navigation  System  (PLANS)  to  meet  this  requirement. 

A  preliminary  integrated  system  design  was  proposed  by 
DREO  in  1983,  using  a  gyrocompass,  the  vehicle  odometer,  and  a 
Transit  receiver.  Originally  a  method  was  proposed  to  obtain 
heading  from  differential  Transit  measurements  (AZTRANS)  (which 
also  required  the  use  of  two  inclinometers),  but  this  was  found 
to  be  technically  impractical  by  the  receiver  manufacturer  and 
was  finally  abandoned  in  late  1984.  By  this  time  an  alternate 
solution  had  been  developed  at  DREO,  which  uses  an  analytic 
method  of  obtaining  heading  information  from  conventional  Transit 
position  fixes.  The  inclinometers  were  then  eliminated  and  the 
large  gimballed  gyrocompass  was  replaced  with  a  smaller 
directional  gyro  unit  based  on  one  strapdown  tuned  rotor  gyro  and 
one  rate  gyre.  This  newer  gyro  unit  can  gyrocompass  when 
stationary  to  initialise  its  heading,  after  which  it  operates  as 
a  directional  gyro. 

Full  simulation  software  for  a  7  state  Kalman  filter 
based  system  was  developed  on  a  general  purpose  minicomputer  (LSI 
11/23)  and  was  running  well  by  early  1984.  By  the  end  of  1984 
this  had  been  transferred  to  a  68000  microprocessor  based  real 
time  system,  with  all  necessary  sensors  and  interfaces,  to  create 
the  PLANS  Experimental  Development  Model  ( XDM ) ,  version  1. 

In  early  1985  a  magnetic  heading  sensor  was  added  to 
augment  the  gyro  unit  and  the  necessary  magnetic  compensation 
software  was  developed.  The  PLANS  Kalman  filter  was  expanded  to 
include  a  magnetic  heading  error  state  and  magnetic  measurements. 
Later  in  1985  this  PLANS  XDM  was  field  proven  at  DREO  on  an  M113 
armoured  personnel  carrier  (APC).  In  1986  formal  field  trials 
were  held  in  Petawawa  using  an  M577  Command  Post  vehicle,  to  test 
the  operability  as  well  as  the  position  accuracy  of  PLANS.  This 
resulted  in  the  reports  of  references  2.1.3  and  2.1.4,  which 
verified  the  operability  and  performance  accuracy  of  the  PLANS 
XDM,  and  lead  to  some  recommendations  for  changes  to  the  displays 


and  operator  interaction  routines. 

Also  in  1986  the  Transit  receiver  was  upgraded  to  add  GPS 
capability  and  the  system  integration  software  was  again  expanded 
to  process  GPS  position  measurements  in  the  Kalman  filter.  In 
February  1987  an  Arctic  field  trial  was  held  in  Iqaluit 
(Frobisher  Bay),  which  proved  the  cold  weather,  high  latitude 
performance  of  the  PLANS  XDM. 

In  1988  an  RFP  was  prepared  to  have  an  advanced 
development  model  (ADM)  built.  This  ADM  is  expected  to  be 
delivered  in  early  1990.  Money  has  been  allocated  for  a  limited 
purchase  of  4  more  units  for  immediate  use. 
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2  APPLICABLE  DOCUMENTS 


2.1  PLANS  System  References 


2.1.1-  Project  Tasking  -  Development  of  a  Primary  Land  Arctic 
Navigation  System  6  page  memo,  10055-79-017  (DLAEEM  4), 
17  November  1982 

2.1.2-  "Design  of  an  Optimally  Integrated  Primary  Land  Arctic 
Navigation  System  (PLANS),  Volume  I,  System  Design",  DREO 
Report  No.  946,  J.  C.  McMillan,  DREO,  Sept.  1986. 

2.1.3-  "Primary  Land  Navigation  System",  User  Trial  Report,  Maj. 
Schuter,  Oct.  1986. 

2.1.4-  "PLANS-A  System  Accuracy",  Technical  Evaluation,  J.C. 
McMillan,  Nov.  1986. 

2.1.5-  "PLANS  Users  Guide",  a  brief  guide  to  XDM  operation,  in 
the  form  of  a  file  on  the  DREO  ED  VAX. 

2.1.6-  "An  Integrated  System  for  Land  Navigation",  J.C. 

McMillan,  Annual  Technical  Meeting  of  the  Institute  of 
Navigation,  Jan.  1987,  Annaheim,  reprinted  in  NAVIGATION: 
Journal  of  The  institute  of  Navigation,  Vol .  34,  No.l, 

Spring  1987. 

2.1.7-  Iqaluit  Field  Trial  Report,  in  progress. 

2.1.8-  "An  Integrated  Land  Navigation  System",  Proceedings  of 
the  Position  Location  and  Navigation  Symposium,  Nov. 
1988. 

2.1.9-  "An  Integrated  System  for  Land  Navigation",  AGARDograph 
GCP/AG  314,  on  Analysis,  Design  and  Synthesis  Methods  for 
Guidance  and  Control  Systems,  editor:  C.T.  Leondes. 


2.2  PLANS  Sensor  References 


2.2.1-  "The  Transit  Navigation  Satellite  System",  Thomas  A. 
Stansell,  Magnavox,  R-5933/October ,  1978,  USA 

2.2.2-  SNA  1002B  Dual  Channel  Satellite  Navigation  Antenna  with 
SAW  Filter  Intech,  Inc.  2  page  description  and 
specification,  distributed  by  Bytown  Marine  Ltd. 


-3- 


2.2.3- 


Setra  Systems  Inc., 
specification  sheet 


Model  205-2  Pressure  Transducer 


2.2.4-  Marinex,  Compass  Sensor  Unit  Type  900111,  Jan.  1981 

2.2.5-  Marinex,  General  description,  6  pages. 

2.2.6-  Humphrey,  specifications  and  drawings  for  the  FD31-0101-1 
three  axis  magnetometer. 

2.2.7-  Lear  Siegler  Vehicle  Reference  Unit:  2  page 

advertisement,  plus  written  material  from  a  short 
operators  course. 

2.2.8-  Proceedings  of  the  IEEE,  Special  Issue  on  Global 
Navigation  Systems,  Oct.  1983 

2.2.9-  Magnavox  Report  R-5871E  "Installation  Manual,  MX1107  Dual 
Channel  Satellite  Navigator",  Jan.  1982. 


2.3  Interface  References 


2.3.1-  DREO  Technical  Note  No.  85/28,  Development  of  a  Multiple 
Port  Serial  Interface  Module  for  PLANS,  Marc  Dion,  DREO, 
1985. 

2.3.2-  DREO  Technical  Note  No.  86/21  (preliminary),  Development 
of  a  General  Purpose  Interface  Module  for  PLANS,  Marc 
Dion,  DREO,  1986. 

2.3.3-  Motorola,  MVME600  Analog  Input  Module,  Sept.  1983 

2.3.4-  Two  page  brief  I/O  description  of  Speed-Log  (Lear 
Siegler ) 

2.3.5-  Lear  Siegler  Vehicle  Reference  Unit:  6  page  brief 
description  of  the  communication  protocol  via  the 
RS422A  interface 

2.3.6-  Debounce  circuit  schematic  for  MassTech  Yellow  Jacket  and 
for  Forward/Reverse  micro-switch 

2.3.7-  Analog  Module  board  I/O  pinout 


2.4  Processor  References 


2.4.1-  Motorola,  MVE  110-1,  VMEmodule  Monoboard  Microcomputer 
Users  Manual,  Mar.  1983 

2.4.2-  68000  memory  map  as  configured  for  PLANS,  1  page 

2.4.3-  Motorola,  MVME210  RAM/ROM/EPROM  Memory  Module  Users 

Manual,  Aug.  1983 

2.4.4-  Motorola,  MVME200/201,  64K/256K  Byte  Dynamic  Memory 

Module  Users  Manual,  Aug.  1983 

2.4.5-  Sky  Computers  Inc.,  Fast  Floating  Point  Processor:  System 
Integration  Manual,  Sept.  1983 

2.4.6-  Descriptive  literature  on  computer  files:  READ . ME ; 1  and 

FFP3  50  . DOCK ; 1 


2.5  Software  References 


2.5.1-  A  listing  of  software  segment  names  is  given  in  file 
name:  prgm.def 

2.5.2-  DREO  PLANS  source  cod-;  listings 

2.5.3-  PLANS  Data  Flow  Diagrams 
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3  SYSTEM  DEFINITION 


The  Primary  Land  Arctic  Navigation  System  (PLANS)  is  a 
land  vehicle  mounted,  optimally  integrated,  multisensor 
navigation  system  designed  and  prototyped  at  the  Defence  Research 
Establishment  Ottawa,  for  use  by  the  Canadian  Forces  in  the 
arctic.  References  2.1.2  and  2.1.6  of  section  2.1  describe  the 
difficulties  of  this  task,  and  the  means  by  which  PLANS  overcomes 
these  difficulties.  The  accuracy  and  functional  performance  of 
this  Experimental  Development  Model  ( XDM )  have  been  verified 
through  field  trials  in  Ottawa,  Petawawa  and  Iqaluit  (Frobisher 
Bay),  as  reported  in  references  2.1.4  and  2.1.7. 


3.1  General  Description 

PLANS  is  a  multisensor  navigation  system  employing  an 
eight  state  Kalman  filter  (described  in  reference  2.1.8)  to 
provide  optimal  estimates  of  the  vehicle  position,  speed  and 
heading.  The  primary  navigation  information  is  obtained  by  simply 
dead  reckoning  the  heading  and  speed  information  that  is 
continuously  available  from  the  gyrocompass  /  directional  gyro  (a 
Lear  Siegler  Vehicle  Reference  Unit  in  the  PLANS  XDM)  and  an 
odometer  pickoff.  (The  Lear  Siegler  VRU  can  gyrocompass  when  the 
vehicle  is  not  moving  to  provide  an  initial  heading  estimate, 
after  which  it  reverts  to  directional  gyro  (DG)  mode.)  These  are 
autonomous  sensors  (not  relying  on  any  external  transmissions) 
which  together  provide  continuous  position  and  velocity.  All 
other  sensor  information  is  used  by  the  Kalman  filter  to  form 
corrections  to  this  dead  reckoned  position  and  velocity. 

Absolute  positional  information  is  obtained  at  aperiodic 
intervals  from  the  Transit  satellite  system  and  is  available  from 
the  Global  Positioning  System  (GPS)  whenever  the  GPS  satellite 
coverage  is  adequate.  Both  of  these  come  from  a  Magnavox  MX1107 
in  the  PLANS  XDM  which  has  a  two  channel  Transit  receiver  and  a 
single  channel  C/A  code  GPS  receiver.  Since  Transit  requires 
height  information,  a  baroaltimeter  is  combined  by  the  Kalman 
filter  with  computer  generated  data  from  an  elevation  map  to 
determine  an  optimal  height  estimate. 

The  MX1107  is  completely  controlled  by  the  PLANS 
processor.  To  do  this  a  keypad  emulator  was  developed,  allowing 
the  MX1107  keypad  and  display  to  be  removed.  PLANS  itself  is 
controlled  via  a  4x5  keypad,  with  an  8-line  by  20-character 
display . 

A  magnetometer  provides  magnetic  heading,  from  which  a 
true  heading  estimate  is  formed  by  using  a  computer  generated 
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geomagnetic  field  model  and  a  magnetic  calibration  function.  The 
Kalman  filter  uses  this  to  aid  the  directional  gyro  heading.  Thus 
by  using  the  dead  reckoning  {gyro  and  speed)  along  with  whatever 
aiding  sensors  are  available,  an  optimal  estimate  of  the  present 
vehicle  position  and  velocity  is  always  available. 

Sensor  error  detection  and  rejection  routines  are  also 
implemented  to  protect  the  integrated  solution  from  bad 
measurements . 


3.2  Functional  Subunits 

The  PLANS  XDM  consists  of  four  main  functional  subunits, 
as  shown  in  block  diagram  form  in  figure  1. 


Figure  1.  Functional  Subunits 


These  blocks  represent  the  following: 

1-  the  Central  Control  Unit  (CCU)  housing  the  system 
electronics,  (satellite  receivers,  computer  and  interfaces) 
which  can  be  mounted  {shock  mounted  if  necessary)  anywhere 
in  the  vehicle. 

2-  the  Directional  Gyro/Gyrocompass  unit  ( DGG ) ,  which  must  be 
hard  mounted  to  the  vehicle,  preferably  near  the  centre  of 
gravity. 

3-  the  Externally  Mounted  Sensors  (EMS),  consisting  of  a 
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Transit  antenna,  GPS  antenna  and  magnetometer. 


4-  the  Keypad/Display  Unit  ( KDU )  is  presently  a  standard  video 
terminal  (in  the  ADM  it  is  meant  to  be  hand-held  and 
connected  to  the  CCU  by  cable). 


3.2.1  Central  Control  Unit  (CCU) 

This  unit  contains  the  interfaces  to  collect  and  digitise 
the  measurements  plus  the  processor  and  memory  to  store  and  run 
the  software  that  performs  the  navigation  and  waypointing 
algorithms,  the  data  prefiltering  and  Kalman  filtering 
algorithms,  the  failure  detection  and  error  rejection  algorithms, 
and  the  operator  interaction  and  display  driving  algorithms. 

This  unit  also  contains  some  of  the  navigation  sensors: 
namely  the  baroaltimeter  and  the  MX1107-R  Transit/GPS  satellite 
receiver  cards,  with  the  necessary  oscillators.  The  baroaltimeter 
requirements  are  described  in  section  5.3  below,  and  the  Transit 
and  GPS  satellite  receivers  are  described  in  section  5.5. 

The  CCU  also  contains  power  supplies  to  power  everything 
in  the  CCU.  The  CCU  takes  input  from  the  keypad/display  unit 
(KDU),  the  directional  gyro/gyrocompass  unit  ( DGG )  and  the 
externally  mounted  magnetometer  and  satellite  antennas.  The  CCU 
provides  serial  output  to  the  remote  displays  and  the  KDU.  The 
CCU  provides  power  to  the  DGG,  the  KDU,  the  magnetometer  and  the 
remote  displays.  The  CCU  obtains  its  power  from  the  vehicle 
batteries.  Figure  2  of  section  3.3  below  shows  the  basic  contents 
of  the  CCU  and  their  relationships  to  other  PLANS  components. 

3.2.2  Directional  Gyro/Gyrocompass  Unit  (DGG) 

This  unit  performs  the  physical  measurements  necessary  to 
provide  the  required  real  time  inertial  heading  and  attitude  data 
for  processing  by  the  CCU.  This  unit  contains  the  necessary 
gyros,  accelerometers,  electronics  and  processor(s)  to  perform 
true  north  seeking  ( gyrocompassing )  when  the  vehicle  is 
stationary,  and  to  thereafter  dynamically  maintain  the  vehicle's 
heading,  pitch  and  roll.  The  DGG  communicates  with  the  CCU  via  an 
RS422  serial  line.  Power  is  supplied  by  the  CCU.  A  more  detailed 
description  of  the  DGG  requirements  is  given  in  section  5.1 
below. 

3.2.3  Keypad/Display  Unit  (KDU) 

The  keypad/display  unit  is  to  be  a  hand-held  or  lap  held 
unit  for  providing  the  equipment-to-user  interface  to  give  the 
operator  the  ability  to  enter  and  extract  the  information 


-8- 


required  to  meet  the  mission  requirements.  The  information  shown 
on  each  display  shall  be  specific  to  that  display's  function. 
This  XDM  KDU  provides  the  necessary  information,  but  on  a 
standard  video  terminal.  These  displays  are  described  in  more 
detail  in  section  3.5  below. 

3.2.4  Externally  Mounted  Sensors 

The  MX1107  has  two  antennas  (one  for  the  C/A  code  GPS  and 
one  for  the  two  Transit  channels)  that  must  be  mounted  on  the  top 
of  the  vehicle  in  unobstructed  locations.  The  magnetometer  should 
also  be  mounted  external  to  the  vehicle  in  a  location  where  the 
disturbance  of  the  earth's  magnetic  field  by  the  vehicle  and  its 
contents  is  minimal  (at  least  .2  metres  from  any  significant 
amount  of  high  permeability  material  such  as  steel  or  iron).  The 
XDM  magnetometer  is  described  in  section  5.4  below. 


3.3  Interface  Definition 

The  PLANS  is  a  multisensor  system  and  as  such  the  CCU 
requires  interfacing  between  the  processor  and  many  different 
sensors.  Figure  2  identifies  the  major  XDM  components,  their 
interfacing  and  interconnections.  As  can  be  seen  from  this 
figure,  the  processor  communicates  with  the  various  interface 
modules  via  a  data  bus,  and  a  breakout  panel  is  used  to  connect 
these  various  I/O  modules  with  the  sensors. 


3.3.1  Interfaces  to  Vehicle  Supplied  Units 

The  PLANS  unit  is  required  to  interface  to  the  vehicle 
power  system  (see  QSTAG  307)  and  the  vehicle  odometer.  The  Lear 
Siegler  odometer  pickoff  requires  a  pulse  counting  circuit,  which 
is  part  of  the  general  interface  card,  described  briefly  below 
and  more  fully  in  reference  2.3.2. 

3.3.2  Interfaces  to  PLANS  Units  External  to  the  Central  Unit 

System  components  external  to  the  PLANS  XDM  central  unit, 
but  part  of  the  PLANS  system  and  to  which  interfacing  is  required 
are:  two  remote  displays  (LCDs);  two  antennas  (Transit  and  GPS); 
the  magnetometer;  the  directional  gyro/gyrocompass  (Lear  Siegler 
VRU);  and  the  main  keypad/display  unit  (KDU).  There  must  also  be 
a  power  connection  to  the  vehicle's  electrical  system. 

The  Marinex  flux-gate  magnetometer  has  three  output 
lines,  requiring  two  differential  A/D  converters.  The  two 
voltages  are  proportional  to  the  sine  and  cosine  of  the  measured 
magnetic  heading,  as  described  in  references  2.2.4  and  2.2.5.  If 
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this  were  replaced  by  a  3-axis  strapdown  unit,  such  as  the 
Humphry  FD31-0101-1  now  being  tested  on  the  XDM,  there  would  be  3 
voltage  outputs. 

The  Lear  Siegler  VRU  requires  a  single  RS422  serial 
interface,  operating  at  9600  baud,  which  serves  to  control  the 
VRU  and  extract  the  necessary  data  from  the  VRU. 

The  KDU  requires  a  clocked  serial  line  for  the  custom  LCD 
display  and  a  parallel  matrix  interface  for  the  keypad.  These  are 
described  in  more  detail  in  reference  2.3.2. 
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Figure  2.  System  Block  Diagram 


3.3.3  Interfaces  to  PLANS  Units  Internal  to  the  Central  Unit 

The  Central  Control  Unit  contains  two  satellite  receivers 
and  a  baroaltimeter  which  require  interfaces.  The  MX1107 
Transit/GPS  receiver  has  an  RS232  serial  interface  (the  "remote 
computer  interface"  described  in  reference  2.2.9)  operated  at 


-10- 


2400  baud.  The  Setra  baroaltimeter  has  0  to  +5  VDC  analog  output. 


3.3.4  Quad  Serial  Port  interface 


This  module  was  designed  and  built  at  DREO.  It  contains 
four  independent  serial  channels  using  either  the  RS-232C  or  the 
RS-422A  standard.  The  baud-rate  is  switch-selectable  for  each 
channel  and  the  data  format  is  selected  under  software  control. 
One  channel  is  used  for  data  logging,  one  to  interface  with  the 
gyrocompass  and  two  to  interface  with  the  satellite  receiver. 
The  ports  are  configured  as  follow: 


#  USAGE 


FORMAT  BAUD  DATA  FORMAT 


1  Spare  or  data  logging 

2  Lear-Siegler  gyrocompass 

3  MX-1107  remote  interface 

4  MX-1107  external  interface 


RS-232C 
RS-422A  9600 

RS-232C  2400 

RS-232C  600 


8-bit,  odd-parity 
8-bit,  no-parity 
8-bit,  no-parity 


3.3.5  Analog  Input  Module 

This  module,  manufactured  by  Motorola  (VMEmodule 
#MVME600),  provides  a  complete  multi-channel,  12-bit,  analog  data 
acquisition.  It  is  configured  to  provide  8  differential 
channels.  One  channel  is  used  to  read  the  baroaltimeter  and  two 
channels  used  to  read  the  magnetometer  outputs. 


3.3.6  Analog  Module 

The  only  function  of  this  module  is  to  filter-out  noise 
from  some  input  signal  lines.  Though  it  plugs  into  the 
I/O  Channel,  all  the  data  lines  in  and  out  are  accessed  through 
the  front  connector. 


3.3.7  General  Purpose  Interface 

This  module  was  designed  and  built  at  DREO.  It  contains 
all  the  necessary  logic  to  interface  with  a  speed-log  unit,  a 
20-key  keypad,  three  LCD  displays,  a  Magnavox  receiver  and 
provides  256  bytes  of  non-volatile  RAM. 

The  Arma-Brown  gyrocompass  (an  original  candidate  for 
PLANS  heading  sensor  but  later  used  only  as  test  equipment)  is 
interfaced  through  a  parallel  port  of  16  data  and  one  control 
lines.  An  external  synchro-to-digital  converter  is  required. 
This  gyrocompass  is  no  longer  used  and  therefore  this  interface 
is  obsolete. 
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The  odometer  outputs  two  pulse  trains  corresponding  to 
the  distance  travelled.  This  module  incorporates  a  24-bit 
counter  and  the  necessary  latches  to  extract  the  direction  of 
travelling. 


The  keypad  consists  of  an  array  of  SPST  switches  arranged 
in  4  rows  of  5  columns.  This  module  provides  the  necessary  logic 
to  scan  and  debounce  the  switches. 

The  MX-1107  satellite  receiver  is  operated  through  a 
16-key  keypad  which  produces  a  debounced,  active  low  TTL  output. 
This  module  incorporates  the  appropriate  logic  to  properly 
emulate  that  keypad. 

The  XDM  originally  incorporated  a  main  LCD  display  and 
two  remote  LCD  displays  (later  replaced  by  a  standard  video 
terminal).  The  data  is  sent  to  all  the  displays  through  a  common 
serial  link  consisting  of  four  data  and  control  lines.  Each 
display  has  the  necessary  logic  to  demultiplex  the  data  received 
and  to  control  the  LCD  drivers.  This  module  incorporates  the 
logic  to  convert  the  data  into  serial  form,  generates  a 
synchronising  clock  and  the  handshake  signals. 

This  module  also  provides  256  byte  of  non-volatile  RAM 
which  are  no  longer  used  and  had  been  replaced  by  JEDEC- 
compatible  ICs  now  available. 


3.3.8  Dual  Channel  Serial  Port 

This  module,  manufactured  by  Motorola  (VMEmodule 
#MVME400),  provides  two  independent  full  RS-232C  serial 
input/output  ports.  It  is  used  to  connect  to  a  host  and  to  a 
data  logging  recorder  during  development. 


3.3.9  Console  interface 

This  is  the  only  interface  not  accessed  through  the 
I/O  Channel.  It  is  an  RS-232C  serial  interface  used  to  connect  a 
console  terminal.  This  port  is  used  during  development  and 
testing  only.  It  is  located  on  the  CPU  module  (MVME110). 
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3.4  Component  Sources 


3.4.1  Software 

The  real  time  PLANS  software,  together  with  some 
development  and  test  software,  was  developed  entirely  at  DREO. 
Laboratory  development  level  documentation  has  been  produced, 
mostly  in  the  form  of  comments  within  the  code.  This  will  include 
task  descriptions  and  module  descriptions.  The  source  code  shall 
be  C-language  Release  2.2,  March  1983,  Whitesmiths  Ltd.  This 
software  is  described  further  in  section  6  below. 

3.4.2  Commercial  Hardware 

All  hardware  used  in  the  PLANS  XDM  is  commercially 
available  at  the  board  level  or  above  except  for  the  General 
Purpose  Interface  (GPI)  (described  in  reference  2.3.2),  the  Quad 
Serial  Port  (QSP)  (described  in  reference  2.3.1),  and  the  Analog 
board.  The  design  details  of  these  non-commercial  subassemblies 
will  be  provided  with  full  theory  of  operation  descriptions  so 
that  functionally  equivalent  hardware  may  be  designed  or 
purchased  and  integrated  into  the  system. 


3.5  Keypad  and  Displays 

One  keypad  and  three  displays  are  required.  They  are 
identified  as  the  main  display,  the  remote  commander  display,  and 
the  remote  driver  display  (the  two  remote  displays  are  almost 
equivalent,  so  common  hardware  can  be  used).  Custom  LCDs  were 
developed  for  the  XDM  main  and  remote  displays,  as  described  in 
reference  2.1.2,  but  they  feature  geographic  rather  than  grid 
coordinates,  and  heading  in  degrees  from  true  north  rather  than 
mils  from  grid  north.  The  main  LCD  display  has  been  abandoned  for 
reliability  reasons,  and  is  being  emulated  on  the  XDM  by  a  VT100. 


3.5.1  Main  Display  Unit 

The  XDM  main  display  unit  contains  a  display  and  keypad 
with  all  indicators  and  controls  required  for  system  operation. 
This  display  uses  8  rows  of  20  characters,  and  is  visible  under 
all  lighting  conditions  within  the  vehicle.  The  layout  for  this 
display  is  shown  in  figure  3  below,  and  described  in  reference 
2.1.2.  The  XDM  keypad  has  twenty  keys  arranged  as  a  four  row  by 
five  column  matrix  as  shown  in  figure  4  below.  The  main  display 
unit  shall  be  either  hand  held  or  lap  held,  remotely  connected 
via  cable  to  the  CCU.  This  display  shall  be  used  by  both  the 
commander  and  the  navigator  during  the  mission.  The  display  unit 
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shall  be  portable  to  allow  unrestrained  access  and  use  within  the 
vehicle . 
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Figure  4.  Keypad  Layout 


3.5.2  Remote  Commander  Display 

The  XDM  commander  display  is  mounted  on  a  pivoting 
bracket,  inside  the  vehicle  just  below  the  front  of  the  roof 
hatch  of  the  M577  vehicle.  This  placement  allows  the  displayed 
position  and  heading  information  to  be  visible  to  the  commander 
while  he  is  in  an  external  observation  position,  standing  partly 
out  of  the  vehicle.  Simultaneous  viewing  of  this  display  and  the 
main  display  are  possible.  (Note:  The  placement  of  the  display 
will  be  different  for  the  BV-206  over  snow  articulated  vehicle.) 
This  display  does  not  contain  any  controls  required  for  system 
operation. 


3.5.3  Remote  Driver  Display 

The  driver  display  is  mounted  on  a  pivoting  bracket  in 
front  of  the  drivers  position.  It  is  mounted  and  dedicated  for 
the  driver's  use  only,  and  can  be  pivoted  so  that  its  displayed 
data  is  visible  to  the  driver  in  either  a  "sitting  up"  or 
"sitting  down"  position  (ie.  while  driving  with  an  open  hatch  or 
closed  hatch).  This  is  a  passive  display,  without  any  controls 
required  for  system  operation.  (It  does  however  have  controls  for 
display  operations  such  as  brightness  and  heading  display 
format ) . 
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3.5.4  Displayed  Information 

The  XDM  system  is  capable  of  continuously  displaying 
vehicle  geodetic  position  in  the  form  of  WGS-84  latitude  and 
longitude,  in  degrees,  minutes,  seconds  and  tenths  of  seconds,  as 
well  as  UTM  (Universal  Transverse  Mercator)  north  and  east 
coordinates  in  tens  of  metres  (to  nearest  10  metres)  including 
the  zone  number.  It  also  continuously  displays  speed  in 
kilometres/hour  (to  nearest  .1  km/hr)  and  heading  in  degrees  (to 
nearest  .1  degree),  as  well  as  position  accuracy  information,  the 
absolute  time  (Greenwich  Mean  Time)  in  hours,  minutes  and  seconds 
(to  nearest  second).  The  main  display  continuously  displays  a 
status  value,  which  provides  a  quantitative  indication  of  the 
expected  accuracy  of  the  PLANS  position  estimate.  It  also 
displays  specified  waypointing  information. 


3.5.5  Tabular  Summary  of  Displayed  Information 


symbology:  X  information  always  visible  on  display 

S  information  selectable  from  Navigators  keypad 
T  toggled  (selectable)  from  Drivers  (Dr.)  or 
Commanders  (Com.)  display 
not  displayed 


Vehicle 

Filtered 

Filtered 

Filtered 

Filtered 

Filtered 


Information 

(1)  Latitude  and  Longitude  (2) 

Northings  &  Eastings  (3) 

Current  Heading 

Course  Deviation  a)  numerical 

b)  bow-tie 

Current  Speed  (note  (4)  for  *] 


display 

display 


GMT 


Dead  Reckoning  latitude,  longitude,  heading  &  speed 
Magnetic  Heading,  Declination  and  Field  Strength 
Transit  Fix  data:  lat.,  long.,  elevation,  &  time  (5) 
Vehicle  Heading  estimates  (Gyro,  Flux-gate  and  GPS) 


Main  Dr . 

X  X 

S  S 

X  X 

T 

X 

X  * 
X 
S 
S 

s 

s 


Com. 

X 

S 

X 

T 

X 
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Altitude  estimates:  Map,  Baro.,  GPS  and  Filtered 
Position  estimates:  Transit,  GPS,  DR  (6) 

Keypad  response  to  input 


S 


Status  number  (figure  of  quality)  (7) 
System  Status  Information 
Help  Function 


S 

X 

X 

S 

s 


Waypoint  Information  (for  any  wpt.,  maximum  of  6) 
Latitude  and  Longitude 
Northings  &  Eastings 

Desired  Heading  (bearing  of  selected  waypoint) 
Range  to  any  waypoint 


T 


Note  1  :  Filtered  indicates  that  the  data  displayed  is  an  output 
of  the  Kalman  filtering  process 

Note  2  :  all  latitudes  and  longitudes  are  in  WGS-84  coordinates. 

Note  3  :  all  northings  and  eastings  are  in  UTM  (Universal 

Transverse  Mercator)  coordinates  (based  on  the  Clarke 
1866  spheroid  and  NAD  1927  datum). 

Note  4  :  *  A  filtered  speed  is  not  seen  by  the  Driver,  however, 
the  APC  speedometer  shall  be  visible  to  the  Driver. 

Note  5  :  Position  refers  to  the  vehicle,  Elevation  refers  to 
maximum  elevation  of  the  satellite  above  the  horizon. 

Note  6  :  Data  from  these  sensors  has  been  dead  reckoned  to  the 
current  time.  DR  is  the  estimated  position  dead  reckoned 
from  the  initial  position  in  WGS-84  coordinates. 

Note  7  :  the  status  is  a  Number  from  0  to  9 ,  and  is  a  function  of 
the  position  error  covariance  from  the  Kalman  filter. 
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3.6  Operating  Procedures 

Reference  2.1.5  gives  a  more  detailed  description  of  the 
operating  procedure.  The  PLANS  XDM  is  menu  driven,  with  a  "HELP" 
utility,  to  minimise  the  number  of  commands  that  the  operator 
must  remember.  It  is  intended  that  reading  the  keypad  keys  and 
the  displayed  prompts  will  be  sufficient  to  enable  anyone 
familiar  with  the  basic  concepts  of  navigation  to  operate  this 
system. 

3.6.1  Initialisation  Procedures 

The  PLANS  XDM  is  ready  to  start  keypad  initialisation 
immediately  after  power  up.  Initialisation,  including 
gyrocompassing,  takes  no  longer  than  20  minutes,  after  which 
dynamic  navigation  commences. 

3.6.2  Adjustments 

No  other  equipment  adjustments  after  the  initial 
installation  are  required  to  operate  the  system.  There  will  be 
the  facility  to  perform  a  calibration  of  the  magnetometer,  but 
this  special  feature  is  not  intended  for  routine  use.  It  will  be 
recommended  that  this  be  done  only  when  the  vehicle  has  been 
reconfigured,  moved  a  great  distance  from  its  last  calibration 
point,  or  over  a  year  has  passed  since  the  last  calibration. 

3.6.3  Special  Operational  Requirements 

No  special  operational  considerations  are  required  to 
enter  the  shutdown  or  power  off  mode. 
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4  SYSTEM  FUNCTIONAL  CHARACTERISTICS 


4.1  System  Accuracy 

The  system  accuracy  requirement  is  specified  in  QSTAG  615 
Navigation  and  Position  Fixing  Accuracies,  for  patrols  at  extreme 
latitudes.  The  XDM  accuracy,  without  GPS,  has  been  determined  by 
field  trials  in  Petawawa  September  1986  and  in  Iqaluit  (Frobisher 
Bay)  in  February  1987  and  has  been  reported  in  reference  2.1.4. 


4.1.1  Positioning  Accuracy 

Positioning  accuracy  is  better  than  312  meters  95%  (150 
meters  CEP),  even  when  GPS  is  not  available.  (It  is  desirable 
that  positioning  accuracy  be  better  than  100  meters  95%,  which 
can  currently  only  be  attained  during  periods  of  good  GPS 
coverage  or  under  smooth  hard  road  conditions.) 

4.1.2  Heading  Accuracy 

Heading  accuracy  is  better  than  4  degrees  95%.  (It  is 
desirable  that  heading  accuracy  be  better  than  2  degrees  95%, 
which  can  currently  only  be  achieved  at  low  to  medium  latitudes.) 

4.1.3  Time  Accuracy 

Displayed  time  is  accurate  to  at  least  1  second. 


4.2  Resolution  of  Displayed  Data 

4.2.1  Position 

On  all  three  displays  the  vehicles  geodetic  position, 
(WGS-84)  is  continuously  displayed  in  full  latitude  and 
longitude,  in  degrees,  minutes,  seconds  and  fractions  of  a 
second,  to  a  resolution  of  0.1  second  in  each  coordinate 
direction.  The  UTM  northings  and  eastings  are  also  continuously 
displayed  on  the  Main  Display  to  a  resolution  of  10  metres. 

4.2.2  Heading 

The  Main  display  continuously  displays  the  vehicle's  true 
and  desired  heading  in  degrees,  to  a  resolution  of  0.1  degree 
(clockwise  from  true  north  to  the  vehicle  lubber  line).  The 
Drivers  and  Commanders  displays  have  a  switch  to  select  for 
display  either  the  actual  heading  or  the  difference  between  the 
actual  and  desired  heading,  in  degrees,  to  a  resolution  of  0.1 
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degree . 


4.2.3  Steering  Indicator 

The  Drivers  and  Commanders  displays  continuously  display 
an  analog  representation  of  the  difference  between  the  actual  and 
desired  heading,  in  the  form  of  a  "heading  to  steer"  indicator, 
showing  the  direction  and  magnitude  of  the  desired  steering 
correction  needed  to  bring  the  vehicle  onto  the  desired  course. 

4.2.4  Speed 

The  Main  display  continuously  displays  the  vehicle's  true 
speed  in  kilometres  per  hour,  to  a  resolution  of  0.1  km/hr. 

4.2.5  Waypoint  Data 

The  Main  Display  can  on  request  display  the  bearing  from 
one  selected  waypoint  to  another  (the  present  vehicle  position 
being  a  waypoint)  to  the  nearest  0.1  degrees.  This  unit  can  also 
on  request  display  the  distance  to  travel  (range)  to  the  next 
waypoint  to  the  nearest  metre. 


4.3  Keypad  Entry 

A  more  detailed  description  of  the  necessary  sequence  of 
inputs  required  to  operate  the  PLANS  XDM  is  given  in  reference 
2.1.5. 

4.3.1  Coordinate  Entry 

Position  entry  is  accepted  by  the  XDM  in  either  UTM 
northings  and  eastings,  in  kilometres,  or  in  WGS-84  latitude  and 
longitude  coordinates  in  either  degrees,  minutes  and  seconds,  or 
in  degrees  and  minutes  (with  decimal  minutes)  or  in  degrees  (with 
decimal  degrees).  The  resolution  accepted  is  equivalent  of  0.1 
arcsecond  (about  3,  meters)  in  each  coordinate  direction. 

4.3.2  Way  Point  Entry 

The  XDM  allows  keypad  entry  of  up  to  six  way  point 
positions  in  either  UTM  northings  and  eastings  or  in  WGS-84 
latitude  and  longitude,  as  described  in  4.3.1  above,  to  a 
resolution  of  0.1  arcsecond. 

4.3.3  Heading  Resolution 

Keypad  entry  of  the  vehicle's  heading  is  accepted  to  the 
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nearest  0.1  degree  (with  respect  to  the  vehicle  lubber  line  and 
true  north ) . 


4.3.4  Input  Confirmation 

All  keypad  entries  are  echoed  to  the  user  on  the  main 
display  to  provide  positive  feedback  and  confirmation  of  input. 


4.4  Restrictions 

4.4.1  Operational  Interference 

The  presence  of  the  PLANS  does  not  interfere  with  the 
proper  operation  of  the  vehicle  or  the  personnel. 

4.4.2  Active  Devices 

The  system  does  not  use  any  devices  resulting  in 
detectable  electromagnetic,  optical,  or  acoustical  transmissions 
from  the  vehicle. 

4.4.3  Power  Control 

The  PLANS  power  source  can  be  electrically  applied  or 
removed  without  affecting  any  other  vehicle  systems. 

4.4.4  Power  Interruption 

After  interruption  of  power  PLANS  is  capable  of 
continuing  its  operation  by  simply  reinitialising  through  the 
standard  startup  procedure.  The  last  best  values  before  power 
interruption  are  used  as  default  values  at  initialisation. 
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5  SENSOR  PERFORMANCE  CHARACTERISTICS 


The  following  paragraphs  specify  the  operational  and 
performance  requirements  for  the  PLANS  sensors.  Note  that  the 
accuracy  figures  are  given  with  a  desired  confidence  level  of  one 
standard  deviation  (approx.  68%). 

The  primary  sensors  are  the  Gyrocompass  and  the  satellite 
receivers,  and  for  these  the  particular  sensors  chosen  by  DREO 
are  identified.  These  identified  units  have  been  shown  to  be 
capable  of  meeting  the  minimum  system  performance  requirement, 
but  should  not  be  considered  to  be  the  mandatory  selection. 


5.1  Directional  Gyro/Gyrocompass 

The  gyro  unit  shall  be  capable  of  dual  mode  operation:  as 
a  gyrocompass  (at  least  in  stationary  vehicle  mode)  and  as  a 
directional  gyro.  It  shall  also  provide  status  and  dynamic  pitch 
and  roll  attitude.  It  shall  be  capable  of  being  controlled  by  the 
PLANS  computer  (preferably  over  an  RS422  or  RS232  serial  line), 
with  no  direct  operator  interaction.  It  shall  be  capable  of 
gy rocompassing  in  the  target  vehicle  while  it  is  idling,  at 
latitudes  up  to  at  least  80.  degrees  (preferably  83.  degrees). 
The  unit  selected  by  DREO  for  the  PLANS  XDM  is  the  Lear  Siegler 
Vehicle  Reference  Unit  (VRU) ,  which  is  the  heading/attitude 
sensor  for  their  "VNAS"  (Vehicle  Navigation  Aids  System),  and  is 
described  very  briefly  in  references  2.2.7  and  2.3.5.  This  unit 
has  a  settle  time  of  4.5  minutes,  but  several  settles  must  be 
averaged  to  obtain  the  required  gyrocompassing  accuracy  at  high 
latitudes . 

5.1.1  Directional  Gyro  Mode  Accuracy 

The  heading  drift  rate  on  the  Lear  Siegler  VRU  has  been 
measured  to  be  less  than  1.  degree  per  hour,  one  sigma  under  the 
specified  operating  conditions,  and  normally  less  than  .5  degrees 
per  hour.  The  pitch  and  roll  accuracy  were  less  precisely 
measured,  but  should  be  better  than  2.  degrees  each  (one  sigma). 

5.1.2  Gyrocompass  Mode  Accuracy 

The  one  sigma  gyrocompassing  error  in  degrees  shall  be 
less  than  .5  secant( latitude )  over  the  area  of  operation  (between 
60°W  and  140°W  longitude  and  between  60°N  and  84.5°N  latitude). 
This  can  be  accomplished  by  multiple  realignment  if  necessary, 
(using  the  average  settled  heading  value  to  adjust  the  final 
settled  value)  but  must  be  achieved  in  less  than  20  minutes.  It 
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was  found  at  DREO  that  4  settles  on  the  Lear  Siegler  VRU 
accomplished  this. 

5.1.3  Settling  Time 

The  settling  time  must  be  less  than  20  minutes  from 
power-on.  Settling  time  is  defined  as  the  time  required  for  the 
gyro  unit  to  reach  the  specified  gyrocompass  heading  accuracy, 
from  a  cold  start. 

5.1.4  Rate  Limits 

The  gyro  unit  must  be  able  to  accurately  track  the 
expected  maximum  angular  rate  of  the  host  vehicle  (about  2. 
radians  per  second).  The  heading  and  attitude  output  must  be 
available  at  least  once  per  second  (preferably  at  a  10.  Hz. 
rate )  . 

5.1.5  Weight/  Volume/  Power 

The  Lear  Siegler  VRU  weighs  about  4.5  kg.  (10  lbs.),  has 
a  volume  of  about  4662  cubic  centimetres  (284.5  in.  )  and 
consumes  about  58  watts  of  power. 

5.1.6  Reliability 

MTBF  data  is  not  presently  available  for  the  VRU. 


5.2  Speed  Sensor 

This  device  is  an  odometer  pickoff  type,  converting 
odometer  cable  rotation  into  pulses.  The  PLANS  XDM  uses  the  Lear 
Siegler  Distance  Measurement  Unit  (DMU),  which  is  also  a  part  of 
the  VNAS  system.  At  present  the  standard  equipment  on  our  M577 
and  BV206  vehicles  includes  only  one  odometer  cable,  on  one 
track.  (It  would  be  beneficial  to  have  one  on  each  vehicle 
track .  ) 

5.2.1  Resolution 

This  DMU  speed  sensor  provides  a  resolution  of  about  355 
pulses  per  metre  on  the  M577  vehicle  odometer  cable  (or  any  other 
vehicle  odometer  with  similar  revolutions  per  metre).  This 
results  in  a  .01  km/hr  speed  resolution  at  a  1  Hz  sample  rate. 

5.2.2  Vehicle  Direction 

The  speed  sensor  output  indicates  forward  or  reverse 
vehicle  motion. 
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5.2.3  Weight/  Volume/  Power 

The  Lear  Siegler  DMU  weighs  about  0.82  kg.,  has  a  volume 
of  about  1367.  cc,  and  consumes  no  power. 


5.3  Baroaltimeter 


The  PLANS  XDM  uses  a  Setra  high  output  pressure 
transducer,  model  205-2,  as  a  barometric  sensor.  This  is  a  small, 
light  weight,  low  power  sensor,  which  is  sufficiently  rugged  and 
sensitive.  This  unit  is  described  in  more  detail  in  reference 
2.2.3.  Since  this  sensor  is  to  be  mounted  in  or  on  the  central 
control  unit,  which  will  be  mounted  inside  the  vehicle,  the 
environmental  conditions  are  not  as  extreme  as  with  the 
externally  mounted  equipment. 

5.3.1  Pressure  Range 

The  linear  pressure  range  (gage  and  absolute)  is  from  0 
to  25  psi.  to  completely  cover  the  expected  barometric  range. 
(Linear  is  defined  as  less  than  1%  deviation.)  The  region  of 
primary  interest  is  from  10  to  20  psi. 


5.3.2  Accuracy 


According  to  the  manufacturers  specifications,  the  output 
is  accurate  to  within  1.9  mBar  at  constant  temperature,  the 
hysteresis  does  not  exceed  0.0275  psi.  and  the  acceleration 
response  is  less  than  3.5  mBar/g,  pressure  port  axis  only. 

5.3.3  Weight/  Volume/  Power 


The  Setra  205-2  weighs  about  113  grams,  and  occupies 
about  25  cc.  of  volume.  The  required  excitation  is  15  to  30VDC . 
Power  consumption  is  less  than  about  0.2  watts.  The  output  is  DC 
voltage.  The  output  impedance  is  less  than  10  Ohms. 


5.4  Magnetometer 


The  PLANS  XDM  was  originally  built  with 
sensor  unit  900111,  which  is  a  2-axis, 
magnetometer,  described  in  references  2.2.4  and 
being  modified  to  use  a  3-axis  strapdown 
FD31-0101-1)  described  in  reference  2.2.6. 


a  Marinex  compass 
gimballed  marine 
2.2.5.  The  XDM  is 
unit  (a  Humphrey 
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5.4.1  Signal  Representation 

The  gimballed  magnetometer  is  a  2-axis  unit,  which 
measures  field  strength  in  the  locally  horizontal  frame  (with  one 
axis  being  the  projection  of  the  vehicle  centreline  into  the 
horizontal  plane).  The  3-axis  strapdown  unit  measures  three 
orthogonal  components  in  a  vehicle  fixed  frame.  The  strapdown 
unit  will  require  the  PLANS  system  to  have  attitude  information 
(such  as  provided  by  the  Lear  Siegler  VRU)  to  project  these  into 
the  locally  level  frame  (otherwise  it  must  be  assumed  to  be 
level,  with  the  resulting  errors). 

5.4.2  Static  Accuracy 

The  magnetometer  provides  a  one  sigma  static  magnetic 
heading  accuracy  in  degrees  (after  calibration  to  remove  the 
vehicle's  hard  and  soft  iron  effects)  of  better  than  34000/H 
where  H  is  the  horizontal  field  strength  in  nano-Tesla  (nT). 

5.4.3  Dynamic  Accuracy 

The  dynamic  errors  induced  by  normal  vehicle  motion  on 
the  gimballed  unit  degrades  the  magnetic  heading  accuracy  by  not 
more  than  a  one  sigma  value  of  about  10000/H  where  H  is  the 
horizontal  field  strength  in  nano-Tesla  (nT). 

5.4.4  Weight/  Volume/  Power 

The  Humphry  unit  weighs  about  1.0  kilogram  and  occupies 
about  1210  cc  volume.  The  Marinex  unit  consumes  about  1.0  watt, 
but  would  also  require  heating,  whereas  the  Humphrey  unit 
consumes  about  4.5  watts  and  does  not  require  heating. 

5.4.5  Environmental 

Since  this  unit  must  be  mounted  external  to  the  vehicle, 
it  must  be  very  rugged  and  must  operate  at  very  low  temperatures 
(-55°C).  In  order  for  the  Marinex  unit  to  function  during  the 
Iqaluit  trials,  warm  air  from  the  vehicle  was  directed  to  an 
enclosure  around  the  unit. 


5.5  Satellite  Receiver/Processor 

The  PLANS  XDM  uses  the  Magnavox  MX1107R  with  the  GPS 
upgrade  (see  reference  2.2.9).  This  has  a  two  channel  Transit 
receiver  and  a  C/A  code  GPS  receiver.  For  the  XDM  the  MX1107 
electronics  chassis  has  been  removed  from  its  housing  and  mounted 
within  the  PLANS  CCU.  The  MX1107  video  display,  keypad,  battery 
and  housing  have  been  "discarded". 
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5.5.1  Receiver  Requirements 

The  receiver  must  have  the  capability  to  select  and  track 
the  best  one  of  several  coincident  (interfering)  satellite 
passes.  (This  is  required  because  at  higher  latitudes  the  number 
of  coincident  passes  increases  resulting  in  more  interference.) 
The  receiver  must  be  capable  of  complete  remote  control  by  the 
PLANS  computer  (preferably  over  an  RS232  or  similar  serial 
interface),  so  that  no  direct  operator  interaction  is  required 
with  the  receiver.  Since  the  antennas  must  be  mounted  external  to 
the  vehicle  they  must  be  sufficiently  rugged  and  must  operate  at 
very  low  temperatures. 

5.5.2  Output  Data  Requirements 

The  receiver  must  provide  the  correct  information 
necessary  for  PLANS  to  optimally  integrate  the  Transit  position 
fixes,  and  the  GPS  position  and  velocity  measurements.  This 
includes : 


-Greenwich  Mean  Time 

-Transit  fix  mark  (time  of  fix  validity) 

-Transit  satellite  direction  of  travel  (N/S  &  E/W  or 
rising  quadrant) 

-Transit  satellite  maximum  elevation  angle 
-Transit  fix  validity  (quality)  flag 
-Transit  fix  Latitude  and  Longitude  ( WGS84 ) 

-Transit  Satellite  ID 

-GPS  Latitude  ( WGS84 ) 

-GPS  Longitude  ( WGS84 ) 

-height 

-GPS  north  and  east  velocity  components 

-GPS  north,  east  and  vertical  geometric  dilution  of 
precision  (NDOP,  EDOP  and  VDOP) 

-number  of  GPS  satellites  visible 

-status 
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The  GPS  data  must  be  continuously  available  at  a  rate  of  at  least 
.1  Hz. 

5.5.3  Weight/  Volume/  Power 

The  MX1107  console,  as  purchased  with  it's  yoke,  case, 
keypad,  display  and  batteries,  (which  were  removed  for  insertion 
into  the  PLANS  XDM)  weighs  about  38.6  kg,  occupies  about  64,439. 
cc  and  requires  175  watts  maximum.  About  45.  watts  are  used  by 
the  MX1107  display. 


5.6  Power  Supplies 

The  XDM  operates  on  vehicle  power,  which  is  28  VDC.  The 
system  requires  5  VDC  and  ±12  VDC  for  its  computer,  satellite 
receiver  and  sensors.  The  gyro-compass  operates  from  the  vehicle 
power  directly.  Two  DC-to-DC  power-supplies  are  used.  One 
provides  5  VDC  at  36  Amp  and  the  other  ±12  VDC  at  2  Amp. 
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6  PLANS  SOFTWARE 


6.1  System  Software 

The  PLANS  uses  the  VRTX  operating  system,  a  real-time 
operating  system  on  a  4K  PROM.  VRTX  is  written  as  position 
independent  code  so  it  may  be  located  anywhere  in  the  user's 
address  space.  The  VRTX  executive  provides  an  operating  system 
kernel,  in  effect  adding  several  high-level  instructions  which 
allow  the  user  to  create  a  multi-tasking  real-time  system.  The 
VRTX  system  calls  are  grouped  as  follows: 

-  multi-tasking  management  (task  creation  /  deletion  / 
suspension  /  resumption  /  priority) 

-  memory  management  (allocation  /  release  &  partition 
creation  /  deletion) 

-  task  communication  (post  /  pend  /  accept  &  queued  post 
/  pend  /  accept) 

-  interrupt  management  (post  /  qpost  from  interrupt) 

-  clock  support  (get  /  set  time,  delay) 

-  character  i/o  (get  char  /  put  char) 

A  device  driver  is  an  asynchronous  process  that  calls  and 
is  called  by  the  Operating  System.  A  driver  performs  the 
following  functions: 

-  receives  and  services  interrupts  from  I/O  devices 

-  initiates  I/O  operations  when  requested  by  the 
Operating  System  (from  a  user  request) 

-  cancels  in-progress  I/O  operations 

-  performs  device  specific  functions  on  power-up, 
timeout , etc . 

In  particular,  device  drivers  are  required  for  RS232 
serial  lines,  A/D  converters,  odometer  counter,  keypad,  LCD, 
non-volatile  ram  and  the  keypad  emulator. 

A  floating  point  processor  (FPP)  is  required  in  order  to 
perform  the  matrix  arithmetic  in  the  filter.  VRTX  was  changed  to 
initialise  the  FPP  and  to  generate  appropriate  calls  (to  the  FPP 
if  present,  to  software  floating  point  package  if  not) 
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The  PLANS  was  written  in  the  "C"  programming  language.  C 
is  a  general  purpose  programming  language,  originally  written  for 
the  UNIX  operating  system,  but  now  popular  on  many 
micro-computers.  C  provides  the  fundamental  flow  constructions 
required  for  well  structured  programs:  statement  grouping, 
decision  making,  looping  with  termination  test  at  the  top  or  at 
the  bottom,  and  selection  of  one  of  a  set  of  possible  cases.  C 
provides  the  standard  data  types  (char,  short,  int,  float, 
double,  etc.)  and  the  ability  to  define  data  sets  (stuct,  union). 
Most  important,  C  provides  pointers  and  the  ability  to  do  address 
arithmetic,  a  useful  feature  in  most  programs,  especially 
micro-computers.  Arguments  to  functions  are  passed  by  value, 
arrays  are  passed  by  reference.  The  major  advantage  of  C  is  that 
it  reflects  the  capabilities  of  current  computers.  Thus,  C 
programs  tend  to  be  efficient  enough  that  there  is  no  compulsion 
to  use  assembly  language  instead.  The  major  disadvantage  is  that 
there  is  no  standard  utility  routine  package  defined  (I/O,  math, 
etc.)  and  each  compiler  uses  slightly  different  names  or  argument 
lists . 


6.2  Application  Tasks 


An  application  task  exists  for  each  of  the  major 
functions  in  the  PLANS  system.  Figure  5  illustrates  the  overall 
software  structure  and  shows  the  various  tasks.  The  tasks  and 
their  functions  are  described  below. 


6.2.1  Data  Collection  Task  (DCT) 

The  primary  purpose  of  the  Data  Collection  Task  (DCT)  is 
to  provide  an  interface  between  the  device  drivers  (and  thus  the 
sensor  interfaces)  and  the  application  tasks  which  require  the 
raw  sensor  data.  This  involves  initialising  the  sensors  and  the 
collection  of  the  sensor  data  at  specified  rates  (DR,  flux,  baro, 
GPS)  or  as  it  becomes  available  (Transit).  As  well,  DCT  feeds 
velocity  and  altitude  to  the  transit  receiver  and  monitors  the 
PLANS  system  clock  (by  checking  it  against  the  time  at  a  transit 
f  ix ) . 


DCT  is  essentially  a  time  driven  task.  At  periodic 
intervals,  it  wakes  up,  reads  the  various  sensor  interfaces, 
formats  the  sensor  data  using  the  appropriate  data  structure  and 
sends  the  data  to  the  other  application  tasks  requiring  the  data. 
Reading  the  sensor  data  can  be  either  through  the  device  driver 
or  through  another  task  (in  the  case  of  the  transit  data).  After 
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reading  all  the  sensor  data,  DCT  waits  for  the  next  wake-up. 
Figure  6  illustrates  the  general  work  cycle  of  the  DCT. 


6.2.2  Serial  Port  Listener  (TTI2) 

The  VRTX  executive  does  not  provide  a  mechanism  to 
perform  a  device  driver  read  operation,  continue  program 
execution  and  check  at  some  later  time  if  the  read  has  completed. 
This  is  a  useful  feature,  especially  in  the  case  of  serial  I/O, 
where  the  input  might  not  come  for  a  long  time  or  the  output 
might  take  a  long  time  to  do.  In  PLANS,  the  transit  data  is 
received  over  a  serial  port  but  at  indeterminate  aperiodic 
intervals.  If  the  DCT  reads  the  serial  port,  then  it  is  locked 
on  the  device  read  until  transit  data  is  received  (and  no  other 
sensors  can  be  read). 

The  serial  port  listener  task  (TTI2)  reads  the  serial 
port  connected  to  the  transit/GPS  receiver.  When  a  read 
completes,  the  ASCII  data  is  sent  to  the  DCT  and  another  read  is 
issued.  In  this  way,  the  serial  line  is  continuously  monitored 
for  transit  data  and  the  DCT  is  free  to  collect  data  from  the 
various  sensors  at  the  required  rates.  Figure  7  illustrates  the 
general  work  cycle  of  the  TTI2  task. 

Nothing  is  ever  as  simple  as  it  seems.  The  transit  data 
is  contained  in  two  transmission  blocks.  The  first  block  is  sent 
automatically  by  the  receiver.  The  second  must  be  requested 
specifically.  As  well, both  transit  and  GPS  are  received  on  the 
same  serial  port  (GPS  also  requires  two  transmission  blocks). 
TTI 2  requests  these  extra  blocks  in  order  to  minimise  delays  in 
processing  the  data. 


6.2.3  Navigation  Task  ( NAVGTR ) 

The  navigator  task  (NAVGTR)  provides  the  display  task 
with  continuous  up-to-date  position,  velocity  and  status 
information.  To  do  this  effectively,  this  means  that  NAVGTR  must 
perform  the  pre-filtering  and  dead-reckoning  functions. 
Pre-filtering  involves  continuity  and  reasonableness  testing  of 
the  sensor  data.  Dead-reckoning  involves  integrating  heading  and 
speed  from  a  time  TO  to  time  T1  and  knowing  the  position  at  time 
TO  to  find  the  position  at  time  Tl .  Doing  these  functions  in  a 
separate  NAVGTR  task  rather  than  the  filter  task  allows  the 
system  to  provide  the  user  with  real-time  information  and  also  to 
perform  Kalman  filtering  of  sensor  inputs  in  a  background  mode. 
As  well,  the  NAVGTR  provides  gyro  settling/alignment  information 
to  the  user.  For  the  Lear  Siegler,  the  system  performs  multiple 
alignments  and  uses  the  average  as  the  initial  heading. 
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The  NAVGTR  task  is  data-driven  in  the  sense  that  it 
performs  its  functions  on  the  data  as  it  receives  the  data.  It 
does  not  request  data  and  relies  on  other  tasks  providing  the 
data  at  appropriate  intervals  (although  all  data  is  time-stamped 
as  it  is  requested  by  DOT).  As  part  of  the  pre-filtering 
process,  it  maintains  statistics  on  sensor  data  errors.  Figure  8 
illustrates  the  general  work  cycle  of  the  NAVGTR  task. 


6.2.4  Kalman  Task  (KALMAN) 

The  purpose  of  the  filter  task  (KALMAN)  is  to  implement 
the  Kalman  filter  based  sensor  blending  algorithms.  Reference 
2.1.2  provides  a  description  of  the  analysis  and  design  process 
by  which  this  task  was  developed.  Some  of  the  functions  of  this 
task  are  to  propagate  the  covariance  matrix  and  state  vector  from 
the  last  update  to  the  current  point  in  time,  to  form  the  filter 
measurements  from  the  sensor  data,  to  perform  the  residual  tests 
on  these  measurements  and  to  process  the  measurements  using  the 
Kalman  update  algorithm.  This  task  also  includes  a  prefilter, 
which  preprocesses  some  of  the  measurements  to  apply  corrections 
or  suppress  noise.  For  example,  since  the  baroaltimeter  could 
have  a  large  bias  error  if  used  alone,  an  elevation  map  is  used 
to  bound  this  error.  As  well,  the  fluxgate  can  have  a  large 
error  (since  the  magnetic  north  is  not  the  north  pole)  so  a 
geomagnetic  field  model  is  used  to  correct  this  error.  Some 
prefilter  averaging  is  also  applied  to  the  magnetic  measurements. 

The  KALMAN  task,  like  the  NAVGTR  task,  is  data  driven. 
It  processes  the  data  as  it  is  received  and  relies  on  other  tasks 
to  perform  the  timing  functions.  Since  the  NAVGTR  task  performs 
the  dead-reckoning,  it  is  not  critical  that  the  KALMAN  task 
perform  the  filtering  functions  in  less  than  the  dead-reckoning 
time  interval  (although  the  smaller  the  delay,  the  better  the 
real-time  accuracy).  Figure  9  illustrates  the  general  work  cycle 
of  the  KALMAN  task. 


6.2.5  Keypad  Task  (KPU) 

The  Keypad  Task  (KPU)  allows  the  user  to  enter 
information  to  the  PLANS  system  through  the  keypad.  The  PLANS 
system  might  need  this  information  for  system  initialisation  or 
it  might  be  an  operators  response  to  a  prompt  from  one  of  the 
function  keys.  These  keys  allow  the  user  to  request  waypoint 
functions  (entry,  display,  activation,  deactivation),  display 
selection  (sensor  data,  system  data,  comparison  data  or  UTM 
information),  help  information  (general  help  or  specific  to  a 
prompt  if  pressed  in  response  to  the  prompt)  and  miscellaneous 
functions  (change  gyro  mode,  transparent  mode  to  the  MX1107). 
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The  primary  objective  of  the  KPU  was  that  it  should  be 
user-friendly.  To  achieve  this  objective,  several  techniques 
were  used.  First,  the  system  automatically  entered  the  startup 
sequence  on  power-up  and  function  keys  allowed  the  user  to  select 
the  area  of  interest.  Prompts  tell  the  user  what  input  is 
required  and  default  answers  to  the  prompt  show  the  response 
format  and  provide  easy  responses  for  most  prompts.  An  on-line 
help  function  key  gives  a  more  detailed  explanation  of  a  prompt 
if  pressed  in  response  to  the  prompt  (it  gives  general  help  if  no 
response  is  requested).  Finally,  all  user  input  is  echoed  to 
provide  positive  visual  feedback  of  input.  As  well,  rubout  and 
clear  keys  allow  corrections  to  be  made  quickly  and  easily. 
Reference  2.1.5  provides  a  more  detailed  description  of  these 
features . 

The  KPU  task  accepts  input  from  the  user,  either  in 
response  to  a  prompt  or  triggered  by  a  function  key.  Once  a 
function  is  initiated  (through  the  function  key),  it  leads  the 
user  (prompts)  through  all  the  steps  necessary  to  implement  the 
function.  At  that  point,  the  information  is  given  to  the 
appropriate  task  for  implementation  and  the  KPU  waits  for  the 
next  user  request.  Figure  10  illustrates  the  general  work  cycle 
of  the  KPU  task. 


6.2.6  Display  Task  (CDU) 

The  Display  Task  (CDU)  formats  all  data  shown  on  the 
central  display  unit  and  on  the  driver/commander  displays.  The 
formatting  of  the  data  involves  selecting  the  information  from 
the  proper  data  structure,  converting  the  data  into  the 
appropriate  units  and  sending  the  data  to  the  correct  field  of 
the  display  at  the  appropriate  intervals.  The  driver/commander 
display  is  sent  position,  heading  and  desired  heading  on  a 
continuous  (every  second)  basis.  The  central  display  is  sent 
time,  position,  heading,  speed,  status  and  desired  heading  on  a 
continuous  (every  second)  basis.  As  well,  the  bottom  three  lines 
of  the  central  display  are  used  to  display  information  selected 
by  the  user.  This  might  be  sensor  data,  comparison  data,  error 
states,  filter  states,  waypoints  or  UTM  information.  The  keypad 
task  can  allocate  these  three  lines  for  itself  (for  prompts)  and 
the  display  cannot  use  them  until  they  have  been  deallocated. 

The  CDU  task  is  a  time-driven  periodic  task  in  the  sense 
that  at  specific  times  it  wakes  up,  checks  to  see  if  new  displays 
or  waypoints  have  been  selected  and  then  displays  the  requested 
data.  Figure  11  illustrates  the  general  work  cycle  of  the  CDU 
task . 
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6.2.7  Data  Logger  Task  (LOGGER) 

The  Data  Logger  Task  (LOGGER)  is  responsible  for 
formatting  binary  data  into  a  block  suitable  for  transmission 
over  a  RS232  serial  line.  As  well,  the  task  requesting  the  data 
logging  can  specify  that  the  data  is  to  be  time-stamped  by  the 
logger  task. 

The  LOGGER  task  receives  blocks  of  data  for  logging  from 
various  tasks.  It  treats  these  blocks  as  an  array  of  bytes  which 
are  then  split  into  most  significant/least  significant  nibbles  (a 
nibble  is  4  bits).  The  nibbles  are  converted  to  the  ASCII 
representation  of  a  hexadecimal  digit  and  this  string  of  hex 
digits  is  transmitted  over  the  serial  line. 

The  following  table  summarises  the  sizes  of  the 
application  tasks  in  the  PLANS  system. 


TASK 

Lines 

of  Code 

Object  Size(bytes) 

KPU 

3100 

27000 

CDU 

900 

12000 

NAVGTR 

900 

11000 

KALMAN 

2100 

30000 

DCT 

850 

7500 

TTI 2 

100 

700 

LOGGER 

200 

750 

Library 

1200 

11000 

RAM 

32000 

Non-Volatile 

RAM 

1000 

6.3  Inter-Task  Communication 

Inter-task  communication  generally  fits  into  one  of  the 
following  five  categories: 

-  initialisation  data 

-from  the  keypad  task  to  the  data  collection  task, 
navigator  task  and  filter  task 

-  Operator  data 

-from  the  keypad  task  to  the  display  task 

-  Raw  data 

-from  the  data  collection  task  to  the  navigator  task 
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-  Prefiltered  data 

-from  the  navigator  task  to  the  filter  and  display  tasks 

-  Processed  data 

-from  the  filter  task  to  the  display,  navigator  and  data 
collector  tasks 

All  of  the  above  data  also  goes  to  the  data  logger  for 
recording  on  cassette  (/magnetic  tape/winchester/etc.)  to  allow 
post-analysis . 

The  Data  Flow  Diagrams  Level  1  and  2  with  an  associated 
Data  Dictionary,  in  reference  2.5.3,  give  a  more  detailed 
description  of  data  flow  within  the  PLANS  system. 
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Figure  6.  Data  Collection  Task 
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Figure  7.  Serial  Port  Listener 
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Figure  9.  Kalman  Filter  Task 


-39- 


-41- 


7  PLANS  PROCESSOR 


The  experimental  development  model  ( XDM )  of  the  Primary 
Land  Arctic  Navigation  System  which  has  been  built  at  DREO 
incorporates  all  the  required  characteristics  along  with  some 
features  useful  during  development  and  testing.  This  section 
gives  a  brief  description  of  the  XDM  processor/interface  hardware 
as  configured  during  development. 


7.1  Bus  Configuration 


The  XDM  was  developed  around  a  VMEbus  configuration  for 
high-speed  access  to  the  co-processor  and  memories.  It  also 
incorporates  a  secondary  bus,  the  I/O  Channel,  to  allow  access  to 
the  slower  I/O  interfaces.  All  the  VMEbus  modules  are  of  double¬ 
height  Eurocard  format  (160  mm  x  234  mm)  and  all  I/O  Channel 
interfaces  are  of  single-height  format  (160  mm  x  100  mm).  The 
XDM  chassis  and  backplane  assembly  has  room  for  5  VMEbus  modules 
and  10  I/O  Channel  modules. 


7.2  Processor/Accelerator 


The  processor  module  selected  for  PLANS  is  the  Motorola 
MVME110 .  It  is  a  high  performance  processing  module  using  an 
MC68000  16-bit  microprocessor  running  at  8  MHz.  The  module 
provides  full  support  for  the  VMEbus  addressing  and  control  logic 
and  will  act  as  the  system  controller.  It  also  provides  support 
for  the  I/O  Channel  used  in  all  the  I/O  operations.  It  also 
includes  a  RS-232C  serial  port  and  a  triple  16-bit  counter/timer. 
On-board  sockets  are  used  to  provide  128  Kbytes  of  EPROM  and 
32  Kbytes  of  write-protectable  RAM. 

The  XDM  incorporates  a  Fast  Floating  Point  Processor  from 
SKY  Computer  ( SKYFFP ) .  It  is  a  single  board,  double-width  VME 
module  that  conforms  to  the  IEEE  single  and  double  precision 
floating  point  standard.  The  SKYFFP  is  referenced  by  the  CPU 
through  a  set  of  registers  and  therefore  is  not  a  true 
co-processor.  The  SKYFFP  is  compatible  with  multi-user 
environments.  The  SKYFFP  performs  the  basic  operations  on  single 
and  double  precision  numbers  and  also  some  more  complex 
operations  (square-roots,  trigonometric  and  transcendental)  on 
single  precision  numbers.  However,  only  the  basic  functions  are 
used.  Typical  execution  time  for  the  basic  functions  is  4.5  //sec. 
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7.3  Memory 


The  XDM  is  built  around  a  ROM-based  microcomputer  system. 
All  the  system  software  (real-time  operating  system,  I/O  drivers, 
libraries,  etc.)  and  all  the  application  tasks  (Kalman  filter, 
data  collection,  navigation  tasks,  etc.)  are  burnt-in  EPROM. 
This  is  how  the  memory  is  partitioned.  The  CPU  module  holds  four 
pairs  of  sockets,  which  provides  128  Kbytes  of  EPROM  containing 
all  the  system  software  and  32  Kbytes  of  RAM  containing  the 
vector  table  and  the  operating  system  data  base.  An  MVME201 
module  provides  additional  256  Kbytes  of  RAM  of  which  48  Kbytes 
are  allocated  to  the  system  pool  where  the  tasks'  stacks  and 
local  variables  are  assigned,  16  Kbytes  are  defined  as  the  user 
pool  where  additional  local  or  sharable  memory  can  be  dynamically 
allocated  to  tasks,  64  Kbytes  are  used  to  download  new  system 
software  in  development  and  128  Kbytes  used  to  download  new 
application  software  or  diagnostics  during  development.  An 
MVME211  module  populated  with  2764  or  27128  EPROM  provides  up  to 
256  Kbytes  of  permanent  data  storage  for  the  application  tasks 
and  diagnostics.  An  MVME210  module  fully  populated  with 
non-volatile  RAM  also  provides  32  Kbytes  permanent  read/write 
memory  of  which  24  Kbytes  are  used  to  download  new  version  of  the 
operating  system  during  development  and  1  Kbyte  is  used  as  a 
permanent  save  area  by  the  application  tasks.  All  the  MVME 
modules  are  built  by  Motorola. 


7.4  Future  Processor/Interface  Requirements 

The  XDM  was  developed  and  built  at  DREO  over  a  number  of 
years.  A  VMEbus  configuration  with  I/O  Channel  capability  was 
selected  at  the  beginning  though  very  few  boards  were  available 
at  the  time.  We  have  seen  in  the  last  few  years  a  proliferation 
of  VMEbus  products  and  now  hundreds  of  vendors  offer  a  wide 
variety  of  VMEbus  products  and  components.  Better  performance 
can  now  be  achieved  with  fewer  boards  and  at  cheaper  cost.  A 
wide  selection  of  I/O  interfaces  are  now  available  for  the 
VMEbus . 


7.4.1  Processor/Memory 

The  PLANS  ADM  processor  and  its  associated  floating  point 
co-processor  or  accelerator  should  have  a  throughput  at  least 
equal  to  the  XDM  and  use  one  of  the  Motorola  68000-family 
microprocessors.  The  system  would  preferably  be  VMEbus-based . 
The  system  should  include  at  least  256  Kbytes  of  EPROM,  32  Kbytes 
of  system  RAM,  64  Kbytes  of  user  RAM  and  1  Kbyte  of  non-volatile 
RAM.  Software  updates  should  be  easily  applied. 
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7.4.2  I/O  Interfaces 


I/O  Interfaces  for  all  the  sensors  and  peripherals  are 
obviously  required.  Whether  they  interface  to  VMEbus  or  the 
I/O  Channel  has  still  to  be  defined  and  will  depend  on 
availability  and  cost  effectiveness. 

7.4.3  Expansion 

The  system  should  provide  several  empty  VMEbus  slots  for 
future  enhancements  or  updates. 
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